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DETAILED ACTION 
Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
Invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner In which the Invention was made. 

Claims 1-4, 6, 7 and 12 are rejected under 35 U.S.C. 103(a) as being as being 
unpatentable over Bertrand et al (US006876640B1 ) in view of Feeney et al 
(US00578677). 

Regarding claims 1, and 7, Bertrand discloses a method and system for 
multicasting/broadcasting IP data (see Fig. 1, a PDSN communicates with a mobile via 
the IP network and radio network, col 6 lines 23-43) the mobile communication system, 
comprising the steps of: 

-a packet data serving node (see Fig. 1, PDSN 120) receiving multicast packet 
data (see Figs. 1 & 2, col 6 line 23-43; When the PDSN 120(1) searches for a PPP 
context for a particular mobile station, such as the mobile station 102(1), the PDSN 
120(1 ) sends a query on the multicast address and port. PPP Registers that listen on 
the multicast address and port, such as the PPP register 126(1 ), respond to the PDSN 
120(1 ) so that the PDSN 120(1 ) receives a response from each of the PPP registers 
that can be reached through the multicast address and port.); 

-transforming the multicast packet data to a PPP frame format having an 
identification header (The multicast data is encapsulated into a standard PPP frame 
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format through a variety of protocols for example by layer two tunneling protocol see col 
2 lines 30-35, the PPP context (session negotiation of PPP with mobile station and 
PDSN) contains number of different parameters such as user ID, protocol identifier, see 
col 3 lines 10-20); 

-transmitting multicast message to base station controller/packet control function 
(See Figs 1 & 2, col 4 lines 50-66. The PDSNs 120(1), 120(2) and 120(3) are 
responsible for establishing, maintaining, and terminating PPP sessions with mobile 
stations such as the mobile stations 102(1), 102(2) and 102(3), thus when the mobile 
station 102(1), which is being served by the RN 108(1), desires to begin a PPP 
session, the mobile station 102(1) sends a connection message 202 to the serving RN 
108(1). Responsive to receipt of the message 202, the RN 108(1) generates an R-P 
connection message 204 to the PDSN 120(1 ) (assuming that the PDSN 120(1 ) was 
selected by the RN 108(1 )). Responsive to the R-P connection message 204, the 
PDSN 120(1) executes a PPP negotiation 206 through the RN 108(1) to the mobile 
station 102(1). The Packet Data Serving Node (PDSN) communicates with the BSC to 
add and remove IP multicast flows. It may use IP multicast protocols to manage 
bearers supporting IP multicast flows between itself and the nearest router connecting 
back to the BCMCS content server.); 

-the BSC/PCF transmitting multicasting/broadcasting message to all or some of 
base stations under control of the BSC/PCF according to header information of the 
multicast message (The RNs 108(1 ) and 108(2) are responsible for relaying the PPP 
session data between the mobile stations 102(1), 102(2) and 102(3) and the PDSNs 
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120(1), 120(2) and 120(3), thus the radio networks are sinnilar and/or same as base 
station controllers which control and manage one or more mobile stations within its 
sen/ing area. The RNs are connected to an IP network 118, which provides an 
interface to the PDSN and other RNs as appropriate.) 

-and transmitting the multicasting/broadcasting message to mobile station 
through broadcasting channel (The RNs 108(1) and 108(2) are responsible for relaying 
the PPP session data between the mobile stations 102(1), 102(2) and 102(3) and the 
PDSNs 120(1), 120(2) and 120(3). The radio networks are similar and/or same as base 
station controllers which control and manage one or more mobile stations within its 
serving area, thus the RNs transmit the messages to the mobile stations.). 

Bertrand fails to disclose a header having information for identifying a multicast 
or broadcast message. 

Feeney discloses a header having information for identifying a multicast or 
broadcast message (see Figs. 5 and 7, col 4 line 64-col 5 line 10 and lines 30-40, a 
message header 10b (Fig. 5) is used to specify broadcast or multicast message being 
sent to all or multiple destinations via control bits 32 or 36 as in Fig. 7). Identifying a 
message as multicast or broadcast provides network routing flexibility by routing 
messages only to those nodes which are to receive the message. Thus it would have 
been obvious at the time the invention was made to incorporate the teachings of 
Feeney within Bertrand so as to improve network efficiency by identifying a message as 
multicast or broadcast prior to transmission and than transmitting only to those nodes 
which are to receive the message. 
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Regarding claims 2 and 12, Bertrand discloses transforming the received data to 
a multicast frame data (see col 6 lines 23-43, as the PPP 126 register is queried the 
data can be retrieved either manually or by multicast mechanism and therefore 
transforming the data received data to a multicast data and than adding an IP header 
for transmission through the IP network 118 forming the R-P interface.). 

Regarding claim 3, Bertrand discloses adding multicasting/broadcasting 
identification header for multicasting/broadcasting to a terminal receiving services under 
ll\/IT-2000, PCS, and cellular systems (see Figs. 1 & 2, col 1 lines 62-65, col 3 lines 30- 
43. An identification header information is added as part of the encapsulation of the 
PPP protocol see col 2 lines 29-40.); 

Regarding claims 4 and 6, Bertrand discloses the mobile station receives the 
multicast PPP datagram and passes the data to the higher PPP link or IP layer (see col 
2 lines 30-49, col 7 lines 19-30. The Point-to-Point Protocol (PPP) is a protocol provides 
Point-to-Point access and enables networking over serial lines. PPP is the protocol 
used by the cdma2000 wireless communication standard for communications between, 
for example, mobile stations and Packet Data Service Nodes (PDSNs). Layer Two 
Tunneling Protocol (L2TP) is a method for encapsulating standard PPP through a 
variety of media. L2TP also allows encapsulation of PPP using User Data Protocol 
(UDP) packets. L2TP supports non-IP protocols such as AppleTalk and IPX as well as 
LPSec Security Protocol. L2TP is implemented to provide secure, node-to-node 
communications in support of multiple, simultaneous tunnels in an IP-based network). 



Application/Control Number: 09/987,703 



Art Unit: 2616 



Page 6 



Claims 5, 8-11, 13 and 14 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Bertrand et al (US006876640B1) as applied to claims 1 & 7 above, in 
view of Utsumi et al (US006693896B1 ) and further in view of Feeney et al 
(US00578677). 

Regarding claims 5, 8 and 14, discloses Bertrand discloses a method and 
system for multicasting/broadcasting IP data (see Fig. 1, a PDSN communicates with a 
mobile via the IP network and radio network, col 6 lines 23-43) the mobile 
communication system, comprising the steps of: 

-a packet data serving node (see Fig. 1, PDSN 120) receiving multicast packet data 
(see Figs. 1 & 2, col 6 line 23-43; When the PDSN 120(1) searches for a PPP context 
for a particular mobile station, such as the mobile station 102(1), the PDSN 120(1) 
sends a query on the multicast address and port. PPP Registers that listen on the 
multicast address and port, such as the PPP register 126(1 ), respond to the PDSN 
120(1) so that the PDSN 120(1) receives a response from each of the PPP registers 
that can be reached through the multicast address and port.); 

-transforming the multicast packet data to a PPP frame format having an 
identification header (The multicast data is encapsulated into a standard PPP frame 
format through a variety of protocols for example by layer two tunneling protocol see col 
2 lines 30-35, the PPP context (session negotiation of PPP with mobile station and 
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PDSN) contains number of different parameters such as user ID, protocol identifier, see 
col 3 lines 10-20); 

-transmitting multicast message to base station controller/packet control function 
(See Figs 1 & 2, col 4 lines 50-66. The PDSNs 120(1), 120(2) and 120(3) are 
responsible for establishing, maintaining, and terminating PPP sessions with mobile 
stations such as the mobile stations 102(1), 102(2) and 102(3), thus when the mobile 
station 102(1), which is being served by the RN 108(1), desires to begin a PPP 
session, the mobile station 102(1 ) sends a connection message 202 to the serving RN 
108(1 ). Responsive to receipt of the message 202, the RN 108(1 ) generates an R-P 
connection message 204 to the PDSN 1 20(1 ) (assuming that the PDSN 1 20(1 ) was 
selected by the RN 108(1)). Responsive to the R-P connection message 204, the 
PDSN 1 20(1 ) executes a PPP negotiation 206 through the RN 1 08(1 ) to the mobile 
station 102(1). The Packet Data Serving Node (PDSN) communicates with the BSC to 
add and remove IP multicast flows. It may use IP multicast protocols to manage 
bearers supporting IP multicast flows between itself and the nearest router connecting 
back to the BCMCS content server.); 

-the BSC/PCF transmitting multicasting/broadcasting message to all or some of 
base stations under control of the BSC/PCF according to header information of the 
multicast message (The RNs 108(1) and 108(2) are responsible for relaying the PPP 
session data between the mobile stations 102(1), 102(2) and 102(3) and the PDSNs 
120(1), 120(2) and 120(3), thus the radio networks are similar and/or same as base 
station controllers which control and manage one or more mobile stations within its 
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sen/ing area. The RNs are connected to an IP network 118, which provides an 
interface to the PDSN and other RNs as appropriate.) 

-and transmitting the multicasting/broadcasting message to mobile station 
through broadcasting channel (The RNs 108(1) and 108(2) are responsible for relaying 
the PPP session data between the mobile stations 102(1), 102(2) and 102(3) and the 
PDSNs 120(1), 120(2) and 120(3). The radio networks are similar and/or same as base 
station controllers which control and manage one or more mobile stations within its 
serving area, thus the RNs transmit the messages to the mobile stations.). 

Bertrand fails to disclose the multicast packet data comprising a header 
information including QoS, multicast/broadcast type, multicast/broadcast group, and 
length information including body data of the PPP frame format and message body. 

Utsumit discloses an information receiving method and apparatus (see Fig.1), 
which uses an AM I net set-up-protocol or ASP. The format of the ASP header is shown 
in Fig. 1 1 which includes multicast type, family or group, length, protocol information, 
QoS parameters can also be mapped as shown in Fig. 5 which are used to interpret the 
VPIA/CI values for a link, see col 17 lines 25-37, col 20 lines 5-29. The concept of 
AMInet or high speed protocol is used to quickly and efficiently reserve and release 
resources without thought of use, thus the ASP header is modified and reserved based 
on individual needs of the user. Thus incorporating the ASP protocol header within 
Bertrand would allow expandability of modifying the header as desired based on 
individual or group of users as appropriate. Therefore it would have been obvious at the 
time the invention was made to incorporate the teachings of Utsumit within Bertrand so 
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as to allow expandability of modifying the header as desired based on individual or 
group of users as appropriate. 

Bertrand and Utsumit fail to disclose a header having information for identifying a 
multicast or broadcast message. 

Feeney discloses a header having information for identifying a multicast or 
broadcast message (see Figs. 5 and 7, col 4 line 64-col 5 line 10 and lines 30-40, a 
message header 10b (Fig. 5) is used to specify broadcast or multicast message being 
sent to all or multiple destinations via control bits 32 or 36 as in Fig. 7). Identifying a 
message as multicast or broadcast provides network routing flexibility by routing 
messages only to those nodes which are to receive the message. Thus it would have 
been obvious at the time the invention was made to incorporate the teachings of 
Feeney within Bertrand and Utsumit so as to improve network efficiency by identifying a 
message as multicast or broadcast prior to transmission and than transmitting only to 
those nodes which are to receive the message. 

Regarding claim 13, Utsumit discloses an information receiving method and 
apparatus (see Fig.1 ), which uses an AMInet set-up-protocol or ASP. The format of the 
ASP header is shown in Fig. 1 1 which includes multicast type, family or group, length, 
protocol information, QoS parameters can also be mapped as shown in Fig. 5 which are 
used to interpret the VPIA/CI values for a link, see col 17 lines 25-37, col 20 lines 5-29. 
The concept of AMInet or high speed protocol is used to quickly and efficiently reserve 
and release resources without thought of use, thus the ASP header is modified and 
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reserved based on individual needs of the user. Thus incorporating the ASP protocol 
header within Bertrand would allow expandability of modifying the header as desired 
based on individual or group of users as appropriate. Therefore it would have been 
obvious at the time the invention was made to incorporate the teachings of Utsumit 
within Bertrand so as to allow expandability of modifying the header as desired based 
on individual or group of users as appropriate. 

Regarding claim 9, Bertrand discloses (Fig. 1) PDSN 120 transmitting multicast 
data to the RNs 108 which are same as BSC see Figs. 1 & 2, col 6 line 23-43; When the 
PDSN 120(1) searches for a PPP context for a particular mobile station, such as the 
mobile station 102(1), the PDSN 120(1) sends a query on the multicast address and 
port. PPP Registers that listen on the multicast address and port, such as the PPP 
register 1 26(1 ), respond to the PDSN 1 20(1 ) so that the PDSN 1 20(1 ) receives a 
response from each of the PPP registers that can be reached through the multicast 
address and port.; 

Regarding claim 10, Bertrand discloses adding multicasting/broadcasting 
identification header for multicasting/broadcasting to a terminal receiving services under 
IMT-2000, PCS, and cellular systems (see Figs. 1 & 2, col 1 lines 62-65, col 3 lines 30- 
43. An identification header information is added as part of the encapsulation of the 
PPP protocol see col 2 lines 29-40.); 

Regarding claim 11, Bertrand discloses transforming the received data to a 
multicast frame data (see col 6 lines 23-43, as the PPP 126 register is queried the data 
can be retrieved either manually or by multicast mechanism and therefore transforming 
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the data received data to a multicast data and than adding an IP header for 
transmission through the IP network 1 18 forming the R-P interface.). 

Response to Arguments 

Applicant's arguments with respect to claims 1-14 have been considered but are 
moot in view of the new ground(s) of rejection. 

Conclusion 

Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 
§ 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 
CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 
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Any inquiry concerning this communication or earlier communications from tlie 
examiner should be directed to Raj Jain whose telephone number is 571-272-3145. 
The examiner can normally be reached on M-F. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Chi Pham can be reached on 571-272-3179. The fax phone numbers for 
the organization where this application or proceeding is assigned are (571) 273-8300 for 
regular communications and (571) 273-8300 for After Final communications. 

Any inquiry of a general nature or relating to the status of this application or 
proceeding should be directed to the receptionist whose telephone number is 571-272- 
2600. 

RJ 

August 10, 2006 




